fix(clients): example paths no longer open missing files - #30021

Approvability

Verdict: Approved at bbf6d85

Macroscope's review found this PR approvable — Inline paths remain code unless the file is confirmed to exist, and existing-file chips preserve the written path. The added checks use permission-gated, cached read operations and reject network paths, with no persistent-data changes.

^{You can add or adjust custom eligibility rules. Learn more.}

No actionable comments were generated in the recent review.

Merge Risk: Minimal · up to bbf6d

The identified file-opening concern does not block merging; the link opens the file found in the workspace.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title "fix(clients): example paths no longer open missing files" names the main change: inline-code paths that do not exist stop rendering as file chips. The changeset adds existence checks for in…
Description check		The description follows the template. It has Problem, Change, Scope and approval, and Verification sections. The Problem section explains the bug with an example, expected behavior, and a linked issue…
Linked Issues check		Directly linked issue #29421 requires that a nonexistent path in inline code not become a file chip that drops its directory text and opens a missing-file preview. The minimum outcome is plain inline …
Out of Scope Changes check		The issue scope names apps/web. The change also touches shared and native code: apps/mobile inline-file rendering (markdownDocument.ts, useEnrichedLinkVariants.ts, useExistingInlineFiles.ts,…

Full details: Title check

Explanation

The title "fix(clients): example paths no longer open missing files" names the main change: inline-code paths that do not exist stop rendering as file chips. The changeset adds existence checks for inline file paths across web, mobile, and shared text code, which matches the title's core fix. The title uses the conventional commit format and is specific. It does not name the existence-check mechanism, but it does not need to cover every detail.

Full details: Description check

Explanation

The description follows the template. It has Problem, Change, Scope and approval, and Verification sections. The Problem section explains the bug with an example, expected behavior, and a linked issue. The Change section explains the fix and why it covers web, native mobile, and find-in-thread text. The Scope section invokes the focused obvious-bug exception and explains why it applies, and it notes that no maintainer approval was received. The Verification section lists the checks run, observed before and after results, and what could not be checked, including native-device runtime. The description also includes the model and harness, as the template asks.

Full details: Linked Issues check

Explanation

Directly linked issue #29421 requires that a nonexistent path in inline code not become a file chip that drops its directory text and opens a missing-file preview. The minimum outcome is plain inline code with full text. The reviewed head implements this:

• Web (apps/web/src/components/ChatMarkdown.tsx): per the change summary, inline-code candidates are checked against workspace files, and a chip is rendered only when the check finds the file. fileLinkChip accepts a label override. The head read confirms the existence-gated rendering path and the resolveWorkspaceFilePath and inlineCodeFilePathCandidate imports. The read was truncated, so the inline-code branch was not read line by line.
• Shared existence lookup (packages/client-runtime/src/state/workspaceFileExistence.ts, read at head): a candidate counts as existing only when its metadata entry is non-null, or when a basename or stripped workspace search finds a match. Metadata errors, search errors, pending results, and disconnected lookups count as missing. For the issue example avatars/u1.webp, the lookup contains a slash and is not a basename, so no search runs and the path stays missing.
• Tests: workspaceFileExistence.test.ts covers existing, missing, pending, null-metadata, and UNC cases. markdownInlineFileLinks.test.ts and threadFindText.test.ts cover the mobile and find-text paths.
• Existing files stay clickable. The chip label keeps the path as written, which satisfies the issue's second option.

The author reports a browser check on a saved fixture. The web gate has no dedicated unit test in the change summary. The issue does not require one, so this does not change the verdict.

Full details: Out of Scope Changes check

Explanation

The issue scope names apps/web. The change also touches shared and native code: apps/mobile inline-file rendering (markdownDocument.ts, useEnrichedLinkVariants.ts, useExistingInlineFiles.ts, EnrichedMarkdownText.tsx, SelectableMarkdownText types), packages/client-runtime (workspaceFileExistence.ts, projectCommands.ts), and packages/shared/src/threadFindText.ts.

These changes connect to the reported behavior:

• The same inline-code file-chip behavior exists on native rendering and in find-in-thread text. The threadFindText change makes searchable text match the code text shown for inline paths.
• The mobile escaping applies to labels of rewritten inline-file links only.
• The client-runtime lookup is the shared existence check that the web and mobile gates use.

No change was shown to be unrelated to the inline-path chip behavior. The shared classifier inlineCodeFilePathCandidate is not modified; the fix gates its output by existence. The author's note that no separate maintainer approval was received is a process matter. It does not show unrelated code.

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

CodeRabbit Verify

• Run CodeRabbit Verify to test the changes in this pull request.

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: cefb544
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: c3a6def5-50b1-4aba-a8b6-2539611288b3

Commits

Reviewing files that changed from the base of the PR and between cefb544 and bbf6d85.

Files selected for processing: 16

• apps/mobile/src/features/files/FileMarkdownPreview.tsx
• apps/mobile/src/features/threads/ThreadFeed.tsx
• apps/mobile/src/lib/markdownDocument.ts
• apps/mobile/src/lib/markdownHtml.test.ts
• apps/mobile/src/lib/markdownInlineFileLinks.test.ts
• apps/mobile/src/native/EnrichedMarkdownText.tsx
• apps/mobile/src/native/SelectableMarkdownText.tsx
• apps/mobile/src/native/SelectableMarkdownText.types.ts
• apps/mobile/src/native/useEnrichedLinkVariants.ts
• apps/mobile/src/native/useExistingInlineFiles.ts
• apps/web/src/components/ChatMarkdown.tsx
• packages/client-runtime/src/state/projectCommands.ts
• packages/client-runtime/src/state/workspaceFileExistence.test.ts
• packages/client-runtime/src/state/workspaceFileExistence.ts
• packages/shared/src/threadFindText.test.ts
• packages/shared/src/threadFindText.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

Verified in a real dev environment

Verified unchanged head bbf6d850401c80adf312bec5fd5546417089e7e9 on Linux with the real dev web client, repository Playwright, /usr/bin/google-chrome, and Codex gpt-6.1-sol through the local proxy. No mocks, saved-message fixtures, or demo provider were used.

Created a local git project and thread through the app. A real Codex turn created and committed the source files. On github/main (cefb544af3c9), its reply rendered nonexistent avatars/u1.webp as a basename-only link; clicking it opened "Unable to load workspace image."

Stopped main before starting the PR, copied only the app-created development state for matching data, and repeated the flow. A fresh Codex turn on the PR also read the real files and produced the reply.

• Missing avatars/u1.webp and missing/example.ts retain their full text as code. Clicking the missing image path opens no panel.
• src/existing.ts:2:1 retains its written label and opens the actual source with line 2 highlighted.
• ./src/__tests__/main.ts keeps its underscores and opens the correct source.
• The explicit Markdown file link still opens the source. npm run dev remains code.
• Find-in-thread finds the complete avatars/u1.webp text and advances between matches.

vp i completed in both checkouts. Blacksmith ran vp test run packages/client-runtime/src/state/workspaceFileExistence.test.ts packages/shared/src/threadFindText.test.ts apps/mobile/src/lib/markdownInlineFileLinks.test.ts apps/mobile/src/lib/markdownHtml.test.ts: 4 files, 66 tests passed. Existing GitHub CI checks passed on this head. No source changes or push were needed.

Not verified

Native iOS/Android and packaged desktop clients were not exercised on this Linux VM. Mobile Markdown and shared lookup tests passed, but they do not prove native rendering. Remote/relay/tunnel connections, Windows paths, disconnected or restricted-permission sessions, cache expiry, and providers other than Codex were not exercised.

this works amazingly well, fixes a long standing bug in t3code and should be merged imo :D

Thanks for the thoughtful fix and verification, Bilal. #29657 by voltcrash addresses the same reported issue by preserving the authored path, and is actively maintained against current main. This branch has had no author update for over a week and main has changed the affected files, so I’m closing it as the duplicate. The other approach still leaves missing paths clickable; if preventing that remains important, please feel free to propose a smaller PR focused on that behavior.